A typical search on the World Wide Web, e.g., on a shopping web site, provides results that may be so numerous that a list of the results may require a user to scroll through the list and/or navigate many pages in order to see all of the results. The results are typically viewed by the user to determine whether there are any listings of interest; e.g., items for purchase, user reviews, ratings, coupons, business profile information, products, auction items, etc. The user may be interested only in a single listing in a set of search results. However, some web sites allow a user to select multiple listings in a set of results and compare the listings in order to improve the efficiency and accuracy of the user's decisions, e.g., to purchase a listing. For example, as is known, selection of a plurality of listings in what may be referred to as a “compare operation” may cause information about the listing to be displayed in a chart or table in a web page.
Unfortunately, known compare operations suffer from a number of shortcomings. For example, a user may be provided a list of web search results having on the order of one hundred (100) listings that match a search query. The user must scroll through the list of listings to determine which listings to view in greater detail and/or compare to other listings. When the user decides that a listing is worth comparing to other listings, present systems and methods require that the user click a standard check box or the like in a graphical user interface (GUI) indicating that the user wants the listing to be compared to other listings. However, the selection of the checkbox (or similar input mechanism) does not initiate the compare operation itself.
Once the user has selected, i.e., checked, the desired checkboxes or the like, present web pages require that the user then visually search the web page for compare links at the top and/or the bottom of a web page providing search results. A compare link, when selected, initiates a compare operation for the selected results. However, depending upon the number of the results, the user may disadvantageously and inefficiently have to scroll an unwieldy distance through the web page in order to find the compare links because the present systems and methods typically locate such links at the beginning or end of the results list. The additional scrolling and searching required to locate a compare link is time consuming, annoying, and may in fact prevent the user from searching, comparing, and purchasing.
Thus, present systems and methods for comparing listings in search results are cumbersome and inflexible. In a large set of results, once a user has selected all of the listings he or she wishes to compare to one another, the user must wade through the results until a compare link is found. This is particularly difficult if the listings chosen for comparison are located near the middle of a page of results. When scrolling long distances, the user may become tired or disoriented, thus making the review of search results inefficient and impractical. Such disadvantages may, for example, dissuade a shopper from using a compare feature in a shopping web site because of the difficulty of making selections, and may prevent selection of search results including purchases based on search results.
According to some previous attempts to solve the foregoing problems a new input mechanism, e.g. a button, is dynamically created next to a listing (on the far right hand side) when it is selected for comparison. This button may be used to initiate a compare operation. However, a serious and common problem in creating new buttons is that when the new buttons appear outside the area that the user is perusing (that is, the selection area), or drawn on a portion of the page not typically used for listing search results, the user may not see the new buttons at all, or the new buttons may be confusing. Such a button is generally not fully drawn on the visible portion of the page depending upon the width of a browser window. Therefore, a user must scroll the page to the right in order to see such new buttons. Moreover, such scrolling occurs only if the user realizes that the newly added buttons exist and are to be used to compare listings. Because the buttons appear physically farther away from the selection area, the user may never see the appearance of the buttons. Moreover, if the button is placed over the listing description, which is often the case due to the limited amount of space available, the layout may be compromised by reducing the amount of information presented about each product that the user is reading to base the compare decision upon. Thus, an additional button that takes away descriptive information creates a situation in which the user is less informed in making a decision based on the comparison of listings in the search results.
New buttons may further distract a user because the user must determine what actions the buttons perform and why the buttons appeared in the first place. Even by looking at and studying new buttons, the user may not know what functions the buttons may activate. This may lead the user to ignore new buttons. The end result of such new buttons is the confusion and frustration of the user.
Accordingly, there is a need for a solution that minimizes the amount of scrolling required by a user wishing to compare products. Such a solution would preferably afford the initiation of a comparison of selected listings from within a set of results. Such a solution would also preferably permit a comparison to be initiated near each selected listing or group of listings. Further, it would be a preferable feature that an input mechanism minimize user of space while still being easily manipulated. Additionally, it would be preferable that the solution appear in the same general location as the selection area so that the user's eyes are already fixed on the location. It would also be desirable that the comparison label be available immediately after any listing is selected. Preferably, the solution would allow for a variety of displayed text or graphics depending on the status of an associated form input with the enablement of an action.